Skip to content

test: lock in CallToolResult(is_error=True) with non-text content (#348)#2841

Open
cognis-digital wants to merge 1 commit into
modelcontextprotocol:mainfrom
cognis-digital:test/issue-348-is-error-non-text-content
Open

test: lock in CallToolResult(is_error=True) with non-text content (#348)#2841
cognis-digital wants to merge 1 commit into
modelcontextprotocol:mainfrom
cognis-digital:test/issue-348-is-error-non-text-content

Conversation

@cognis-digital

Copy link
Copy Markdown

What

Adds a regression test proving a FastMCP tool can return a CallToolResult with is_error=True carrying non-text content (an image), and a matching requirements-manifest entry.

Why

Issue #348 (good first issue, ready for work) reports that there's "no way to set isError=True for arbitrary tool result content" — e.g. returning an image with isError=True.

While looking into it, the capability actually already exists on main: _handle_call_tool and func_metadata.convert_result pass a tool-returned CallToolResult through unchanged, so a tool can return CallToolResult(content=[ImageContent(...)], is_error=True) directly. The existing tests only cover this for text content and for the validation/exception paths — the non-text + is_error case from #348 wasn't pinned anywhere.

This PR locks that behaviour in so it can't silently regress, and documents the pattern in the test docstring. Test-only — no library change.

Verification

  • New test passes across all three transports (in-memory, SSE, streamable-HTTP)
  • tests/interaction/test_coverage.py requirements gate passes (new requirement is exercised; test carries a requirement)
  • ruff format --check, ruff check, and pyright all clean
  • Full tests/interaction/mcpserver/test_tools.py (42 tests) passes

If maintainers would rather close #348 with a dedicated convenience API instead of documenting the CallToolResult passthrough, happy to adjust — this seemed like the lowest-risk way to resolve it.

Closes #348.


🤖 Generated with Claude Code

…delcontextprotocol#348)

A FastMCP tool can already report failure while returning rich (non-text)
content by returning a CallToolResult with is_error=True directly -- MCPServer
passes it through unchanged. This was untested and undocumented, which is what
issue modelcontextprotocol#348 reports ("no way to set isError=True for arbitrary tool result
content").

Add a regression test proving an image content block plus is_error=True
round-trips to the caller over all transports, and a matching requirements
manifest entry (source issue:modelcontextprotocol#348). Test-only; no library change.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

No way to set isError=True for arbitrary tool result content

1 participant